Treatment of Passive Voice and Conjunctions in Use Case Documents

Requirements engineering, the first phase of any software development project, is the Achilles’ heel of the whole development process, as requirements documents are often inconsistent and incomplete. In industrial requirements documents natural language is the main presentation means. In such documents the system behavior is specified in the form of use cases and their scenarios, written as a sequence of sentences in natural language. For the authors of requirements documents some facts are so obvious that they forget to mention them. This surely causes problems for the requirements analyst. Missing information manifests itself, for example, in sentences in passive voice: such sentences just say that some action is performed, but they do not say who performs the action. In the case of requirement analysis this poses a serious problem, as in every real system there is an actor for every performed action. There already exists an approach able to guess missing actors and actions. However, the existing approach is able to handle sentences containing exactly one verb only. The approach presented in this paper extends the existing one by treatment of compound sentences and passive voice. Feasibility of the presented approach to the treatment of passive and conjunctions was confirmed in a case study. 1 Document Authors are not Aware that some Information is Missing Some kind of requirements document is usually written at the beginning of every software project. The majority of these documents are written in natural language, as the survey by Mich et al. shows [1]. This results in the fact that the requirements documents are imprecise, incomplete, and inconsistent. The authors of requirements documents are not always aware of these document defects. From the linguistic point of view, document authors introduce three defect types, without perceiving them as defects (cf. Rupp [2]): 1 Deletion: “. . . is the process of selective focusing of our attention on some dimensions of our experiences whereas excluding other dimensions. Deletion reduces the world to the extent that we can handle.” Generalization: “. . . is the process of detachment of the elements of the personal model from the original experience and the transfer of the original exemplary experience to the whole category of objects.” 1 The following definitions are translations of the definition from [2] (in German) Distortion: “. . . is the process of reorganization of our sensory experience.” It is one of the goals of requirements analysis, to find and to correct the defects of requirements documents. In requirements documents the behavior of the prospective system is often specified as a set of use cases, each use case represented by one or several scenarios (cf. Rupp [2]). A scenario is a sequence of natural language sentences. Each sentence of this sequence represents either some input to the system or the reaction of the system to previous inputs. The presented paper focuses on the “deletion”-defects in scenarios. Deletion manifests itself in scenarios in the form of missing action subjects or objects or even in whole missing actions. One of the reasons for the deletion may be the fact that some information is too obvious for the author of the requirements document, so that she finds it unnecessary to write down this information. One further reason for missing action subjects, manifesting itself in sentences in passive voice, can be the absence of an exact construction plan, typical in the early stages of the project. It is the goal of the approach presented in this paper, to identify missing parts of scenarios written in natural language and to produce message sequence charts (MSCs) containing the reconstructed information. (See Section 3 for an introduction to MSCs.) For the remainder of the paper we use the following terminology: A scenario is a sequence of natural language sentences, each sentence representing some action. A message sequence chart (MSC) is a set of communicating objects and a sequence of messages sent/received by these objects. The remainder of the paper is organized as follows: Section 2 introduces the case study used to evaluate the presented approach. Section 3 introduces message sequence charts (MSCs) and an existing approach transforming scenarios to MSCs. This approach works only for sentences in active voice, containing exactly one verb. Section 4 explains an extention of this approach, allowing both for passive voice and for several verbs in the same sentence. Section 5 presents the evaluation of the approach on a case study. Finally, Sections 6 and 7 present an overview of related work and the summary of the paper, respectively. 2 Case Study: The Instrument Cluster Authors of requirements documents tend to forget to write down facts that seem obvious to them. Even in a relatively precise requirements document, as for example the instrument cluster specification [3], some missing facts can be identified. The instrument cluster specification describes the optical design of one part of the car dashboard (the instrument cluster), its hardware, and, most importantly, its behavior. The behavior is specified as a set of scenarios, like this: 1. The driver switches on the car (ignition key in position ignition on). 2. The instrument cluster is turned on and stays active. 3. After the trip the driver switches off the ignition. 4. The instrument cluster stays active for 30 seconds and then turns itself off. 5. The driver leaves the car. There are apparent problems if we try to translate this scenario to a sequence of messages exchanged by communicating objects. Firstly, there is no one-to-one correspondence between sentences and messages. For example, sentences number 2 and 4 contain two potential messages each: Sentence 2 contains actions “The instrument cluster is turned on” and “The instrument cluster stays active” and sentence 4 contains actions “The instrument cluster stays active for 30 seconds” and “The instrument cluster turns itself off”. Furthermore, for at least one of these actions (“The instrument cluster is turned on”) the actor is not explicitly specified. It is the goal of the approach presented in this paper, to resolve such incomplete specifications and present the results to a human analyst for validation. 3 Scenarios and Message Sequence Charts Message Sequence Charts (MSCs) are a convenient means for concise and precise representation of action sequences. An MSC consists of a set of communicating objects. These communicating objects exchange messages, whereas every message has a well defined sender and receiver. Graphically, communicating objects are represented as rectangles, and messages as arrows; the time line is directed top down (cf. Figure 1). When translating scenarios (written in natural language) to MSCs, it is necessary to deal with typical deficiencies of natural language texts: It can happen that either the message sender or the receiver are not explicitly mentioned, or the whole action is just omitted. For example, if we directly translate the scenario introduced in Section 2 to an MSC, a possible translation is the MSC in Figure 12. The problems of this translation are apparent: there are definitely missing messages from the car to the instrument cluster, otherwise the instrument cluster cannot know that it should be turned on or off. Furthermore, some sentences, like “The instrument cluster is turned on”, do not specify the message receiver. Even if we rephrase this sentence to active voice (“The instrument cluster turns on”), the message receiver remains unspecified. The problem of unspecified message senders/receivers and missing actions was solved in [4] by the organization of MSC messages in a stack. Organization of messages in a stack is motivated by the idea of situation stack by Grosz et al. [5]. Grosz et al. introduce a situation stack to explain how the human attention focuses on different objects during a discourse. The focus depends on the sequence of sentence heard so far. By default, a sentence defines some situation and is pushed onto the stack. If a sentence reverts the effect of some previous sentence, the corresponding stack element is popped: John enters the shop //push “enter” — Some actions in the shop — John leaves the shop //pop “enter” and the above stack elements The idea of the situation stack can be easily transferred to MSCs: It is possible to define an active object as an object that has sent a message but has not received an answer yet. If the receiver of the message under analysis (msg) is an active object, then it is possible to find the topmost message of the stack sent by this object (msg ). Then, 2 To make the figure compacter, “instrument cluster” is abbreviated as “ins. clust.”. driver car ins. clust.